It has been a goal of the software industry to develop standard software components that can be reused and that can be easily combined to form complex systems. It is envisioned that the functionality provided by these software components would be described in much the same way that a data sheet describes a hardware component (e.g., a special-purpose telecommunications chip). Various object models have been defined that provide a standard interconnection mechanism between software components. Under these object models, software components are “objects” in the object-oriented sense, and the software components provide “interfaces” through which their functionality can be accessed. By using interfaces, objects can expose their functionality independently of the implementation of the functionality. In the C++ programming language, an interface is an abstract class whose virtual functions are all pure. A pure virtual function is one that has no implementation in the class. Thus, an interface defines only the order of the virtual functions within the class and the signatures of the virtual functions, but not their implementations. The following is an example of an interface:
class IShape{virtual void draw(int x,y)=0;virtual void save(char filename)=0;virtual void clear(int x,y)=0;}
This interface, named “IShape,” has three virtual functions: draw, save, and clear. The “=0” after the formal parameter list indicates that each virtual function is pure. Concepts of the C++ pro language that support object-oriented programming are described in “The Annotated C++ Reference Manual,” by Ellis and Stroustrup, published by Addison-Wesley Publishing Company in 1990, which is hereby incorporated by reference.
Once an interface is defined, programmers can write programs to access the functionality independent of the implementation. Thus, an implementation can be changed or replaced without having to modify the programs that use the interface. For example, the save function of the IShape interface may have an implementation that saves the shape information to a file on a local file system. Another implementation may save the shape information to a file server accessible via the Internet.
To ensure that an implementation provides the proper order and signatures of the functions of an interface, the class that implements the interfaces inherits the interface. The following is an example of a class definition that implements the IShape interface.
class Shape: IShape{virtual void save(char filename) {. . .};virtual void clear(int x,y){. . .};virtual void draw(int x,y){. . .};virtual void internal saver{. . .};int x;int y;}
The first line of the class definition indicates by the “: IShape” that the Shape class inherits the IShape interface. The ellipses between the braces indicate source code that implements the virtual functions. The Shape class, in addition to providing an implementation of the three virtual functions inherited from the IShape interface, also defines (i.e., introduces) a new virtual function “internal_save,” which may be invoked by one of the implementations of the other virtual functions. The Shape class also has defined two integer data members, x and y.
Typical C++ compilers generate virtual function tables to support the invocation of virtual functions. When an object for a class is instantiated, such a C++ compiler generates a data structure that contains the data members of the object and that contains a pointer to a virtual function table. The virtual function table contains the address of each virtual function defined for the class. FIG. 1 illustrates a sample object layout for an object of the Shape class. The object data structure 101 contains a pointer to a virtual function table and the data members x and y. The virtual function table 102 contains an entry for each virtual function. Each entry contains the address of the corresponding virtual function. For example, the first entry in the virtual function table contains the address of the draw function 103. The order of the references in the virtual function table is the same as defined in the inherited interface even though the Shape class specifies these three functions in a different order. In particular, the reference to the draw function is first, followed by the references to the save and clear functions.
The inheritance of interfaces allows for references to objects that implement the interfaces to be passed in an implementation independent manner. A routine that uses an implementation may define a formal argument that is a pointer to the IShape interface. The developer of the routine can be unaware that the implementation is actually the Shape class. To pass a reference to an object of the Shape class, a program that invokes the routine would type cast a pointer to the object of the Shape class to a pointer to the IShape interface. So long as the pointer points to a location that contains the address of the virtual function table and the virtual function table contains the entries in the specified order, the invoked routine can correctly access the virtual functions defined by the IShape interface.
One popular object model that specifies a mechanism for interconnecting components is Microsoft's Component Object Model (“COM”). COM is more fully described in “Inside COW” by Dale Rogerson and published by Microsoft Press in 1997. COM specifies that each object is to implement an interface referred to as the IUknown interface. The IUnknown interface provides a query interface function, an add reference function, and a release function. The query interface function is passed the identifier of an interface that the object supports and returns a reference to that interface. The add reference and the release functions are used for reference counting the object. Each object that conforms to COM implements the IUknown interface.
A client object that requests to instantiate a COM object may receive a pointer to the IUknown interface in return. The client may then invoke the query interface function passing the identifier of another interface supported by that COM object. The query interface function returns a pointer to the requested interface. The client can then use the pointer to invoke one of the functions of the requested interface. As mentioned above, each interface of a COM object inherits the IUknown interface. Thus, each of these interfaces provides access to other interfaces and provides reference counting. Whenever a client duplicates a pointer to an interface of a COM object, the client is expected to invoke the add reference function, which increments the reference count to that COM object. Whenever the client no longer needs a pointer to an interface to a COM object, the client is expected to invoke the release function, which decrements the reference count to that COM object and destructs the COM object when the reference count goes to 0.
FIG. 2A is a block diagram illustrating conventional interconnections between a server object and client objects. In this example, server object 2A01 includes an interface 2A02. Once the server object is instantiated, various client objects 2A03-2A06 may request a pointer to an interface of the server object using the query interface function. The server object may have no way of identifying which client object invokes a function of the interface. For example, when client object 2A03 invokes a function, the server object cannot determine whether it is client object 2A03 or client object 2A04 that is invoking the function. Some server objects may be developed so that they can identify the individual client object that is invoking a function. Such server objects may provide each client object with its own identifier. For example, after a client object invokes a query interface function of the server object to retrieve a pointer to an interface, the client object, by convention, may then invoke a function of that interface which returns a unique identifier for that client object. When the client object subsequently invokes a function of the interface, the client object passes its unique identification so that the server object can uniquely identify each client that invokes a function.
Such server objects that can uniquely identify clients have a couple of disadvantages. First, the cost of development of such server objects is increased because of the additional code that is needed to support the unique identifications of client objects. Second, each client object needs to be programmed to receive and provide its unique identification. It would be desirable to have a technique in which existing server objects could be used in such a way so that each client object can be individually identified when it invokes a function. It would be also useful if such a technique would not require any modification to existing server class definitions and client class definitions.
FIG. 2B illustrates a typical inheritance of a server class (i.e., Server) by a derivation server class (i.e., DServer). In this example, an instance of the Server class 2B01 inherits the IUnknown interface and includes data members 2B02 and function members 2B03. The function members may include the functions of the IUknown interface and various other functions (e.g., func 1). The DServer class 2B04 inherits the Server class and includes data members 2B05 and function 2B06. The data members include the inherited data members from the Server class and other data members that may be introduced in the DServer class. The functions include the inherited functions from the Server class and other functions that may be introduced in the DServer class. The DServer class provides implementations for each in introduced functions and may provide overriding implementations for the inherited functions.